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1.  INTRODUCTION 

An  important  component  of  the  Packet  Radio  project  is  the 
station  software,  providing  a  variety  of  control,  coordination 
and  monitoring  functions.  BBN's  role  in  developing  this  software 
is  to  specify,  design,  implement  and  deliver  programs  which 
perform  these  functions. 

Progress  during  this  quarter  centered  on  the  Labeler  process 
and  on  TOPS20  monitor  internet  code.  The  Labeler,  which  receives 
reports  of  network  connectivity  and  status,  has  responsibility 
for  controlling  the  network,  primarily  through  assignment  of 
routes.  A  new  Labeler  to  support  version  5  of  the  Channel  Access 
Protocol  (CAP)  has  been  completed  and  is  now  running.  This  is 
reported  in  section  3,  along  with  other  Packet  Radio  network 
issues. 

The  Internetwork  Protocol  effort  has  made  version  4  of 
internet  facilities,  integrated  into  the  DEC  TOPS20  operating 
system,  available.  This  and  other  internetwork  items  are  covered 
in  section  4. 

Section  2  deals  with  meetings,  including  a  Packet  Radio 
Working  Group  (PRWG)  meeting  this  quarter,  and  with  publications 
and  negotiations.  Section  5  covers  hardware  efforts  during  the 
quarter . 
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2.  NESTINGS r  TRIPS ,  PUBLICATIONS 
2.1.  Meetings  and  Trips 

During  this  quarter  BBN  was  involved  in  several  meetings, 
both  for  debugging  and  for  negotiations.  Collins  Radio  personnel 
visited  BBN  facilities  for  debugging  of  PR  hardware  (see  section 
5),  but  also  a  visit  was  made  for  software  debugging.  With  their 
help,  we  diagnosed  a  serious  flaw  in  the  SPP  protocol  used  to 
communicate  between  the  station  and  PRs.  This  is  discussed 
further  in  section  2.3. 

BBN  Personnel  visited  SRI  this  quarter  for  on-site  debugging 
of  CAP  5  station  and  PR  software  and  testing  of  its  performance. 
Some  bugs  in  the  Labeler  were  found  and  fixed.  Another  on-site 
visit  was  scheduled  for  early  August,  for  mobile  testing,  but  was 
postponed  in  favor  of  resolving  continuing  difficulties  locally 
at  BBN,  Collins  and  SRI,  and  cross-net  when  appropriate. 

BBN  hosted  a  June  21  meeting  on  source  notification.  This 
established  a  forum  for  various  discussions  on  how  and  when 
sources  of  internetwork  traffic  should  be  informed  of  error 
conditions.  Such  conditions  include  the  destination  host  or 
network  being  down  or  unreachable;  traffic  being  refused  by  the 
destination  host,  destination  network,  or  an  intermediate 
network;  and  traffic  being  discarded  by  gateways  when  congestion 
occurs.  Another  aspect  of  the  source  notification  issue  involves 
identifying  which  traffic  handling  element  should  generate  the 
notification.  Meeting  minutes  were  prepared  and  made  available. 

BBN  personnel  attended  the  July  11-12  meeting  of  CAP  5 
implementers  at  SRI.  Major  topics  of  discussion  relating  to 
station  software  were  the  SPP  oscillation  problem  and 
consideration  of  eventual  conversion  to  the  "SPP2"  protocol; 
placing  a  value  in  the  "type"  field  of  acknowledgement  packets 
generated  by  the  station  which  matches  that  of  the  packet  being 
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acknowledged;  fast  labeling  and  route  assignment  for  coming  use 
and  demonstrations  at  Fort  Bragg;  potential  need  for  a  PDP-11/23 
miniature  station  at  Fort  Bragg  in  1980;  priority  of  LROP 
generation  in  PRs  (which  had  been  low  enough  that  network  control 
algorithms  were  not  working  well) ;  and  possible  expansion  of  the 
design  of  the  PR  down  line  load  process,  to  permit  delivery  of  PR 
code  to  the  station  via  FTP,  with  supervision  and  direction  from 
an  operator.  All  of  these  issues  constitute  useful  improvements 
to  the  overall  PR  network  design  and  capabilities. 

2.2.  Publications 

This  quarter  four  Packet  Radio  Temporary  Notes  (PRTNs)  were 
released  by  BBN,  two  on  theoretical  issues  and  two  on  design 
specifications.  We  also  sent  a  station  documentation  package  to 
Fort  Bragg.  The  PRTNs  are  summarized  in  the  paragraphs  below. 

PRTN  271,  "SPP  Heterostate  Diagram* 

This  paper  explains  and  motivates  the  SPP  protocol.  The 
intention  was  to  publish  this  document  some  time  ago,  in 
conjunction  with  PRTN  177,  "SPP  Definition".  While  PRTN  177  is 
technically  complete,  the  complexity  of  SPP  is  more  easily 
grasped  when  it  is  broken  down  into  constituent  pieces.  Each 
piece  solves  a  different  constraint  problem  relevant  to  the 
operational  environment  in  which  SPP  must  operate.  In  addition 
to  this  decomposition,  PRTN  271  also  provides  a  simple  graphical 
notation  (the  "heterostate  diagram")  to  convey  all  the  major 
aspects  of  SPP.  This  paper  is  published  now  largely  in  response 
to  the  ongoing  negotiations  over  SPP  and  the  proposed  simplified 
SPP,  SPP2.  These  arose  in  turn  because  of  the  SPP  oscillation, 
triggered  by  Performance  Data  Packets  originated  by  PRs  with  both 
"open"  and  "close"  SPP  indications  asserted. 
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PRTN  272,  *SPP  Oscillation" 

This  paper  documents  and  describes  the  oscillation  diagnosed 
this  quarter  by  BBN  and  visiting  Collins  staff.  It  is  due  to 
each  end  device  alternately  executing  the  required  opening  and 
closing  of  a  connection  on  which  it  has  not  transmitted,  but 
which  has  been  closed  by  the  remote  end.  This  oscillation  is 
inherent  in  SPP,  but  was  not  known  or  experienced  until  CAP  5,  in 
which  PRs  first  take  the  initiative  to  generate  traffic.  This 
note  also  discusses  solution  alternatives,  including  the  timeout 
we  have  adopted  in  station  software.  It  also  discusses  why  the 
Transmission  Control  Protocol  (TCP) ,  a  more  robust,  internet 
protocol,  is  not  subject  to  this  type  of  oscillation. 

PRTN  276,  "Specifications  of  New  Packet  Radio  Down-line 
Loader" 

This  document  presents  the  capabilities  of  the  new  PR  down 
line  load  process  (PRLOAD) .  In  particular,  both  Experimental  and 
Improved  types  of  Packet  Radio  units  (EPRs  and  IPRs)  will  be 
serviced,  with  easy  expandability  to  Low-cost  and  Ultimate 
varieties  (LPRs,  UPRs) .  In  addition,  the  station  operator, 
through  terminal  dialog  with  PRLOAD,  will  specify  a  service  host 
and  file  name  from  which  PRLOAD  will  FTP  new  PR  code,  placing  it 
on  station  disk. 

PRTN  277,  "A  Simple  Fairness  Algorithm" 

This  paper  presents  a  solution  to  a  task  scheduling  problem 
in  PRs.  The  PR  control  structure  is  a  loop  consisting  of 
successive  tests  of  whether  various  tasks  can  be  performed.  When 
a  ready  task  is  found,  that  task  is  serviced,  after  which  control 
returns  to  the  top  of  the  loop.  If  tasks  tested  early  in  the 
loop  are  ready  often  enough,  tasks  later  in  the  loop  will  never 
be  tested,  not  to  mention  serviced.  The  paper  proposes 
suppressing  each  particular  task  on  certain  passes  through  the 
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loop,  thus  guaranteeing  all  tasks  at  least  some  level  of  service. 
2.3.  Negotiations  and  Informal  Documents 

The  most  significant  negotiations  this  quarter  revolved 
around  the  oscillation  possible  in  the  Station-to-PR  Protocol, 
SPP.  We  found  that  the  CAP  5  station  and  PR  would  sometimes 
enter  an  unending  cycle  of  sending  empty  (textless)  packets  back 
and  forth.  This  was  particularly  easy  to  reproduce  in  the  BBN  PR 
net,  where  packet  printing  is  presently  performed  on  a  ten 
character  per  second  terminal,  which  is  slower  than  elsewhere. 
Down  line  loading  the  non-station  PR  would  precipitate  the 
sequence  of  events,  which  would  so  congest  the  connection  process 
that  the  down  line  load  in  effect  ceased.  On-site  debugging  by 
Collins  staff  helped  to  clarify  the  PR's  role  in  this  sequence, 
and  the  conclusion  was  reached  that  the  oscillation  is  a 
potential  problem  inherent  in  the  design  of  SPP.  This,  and  the 
20-second  timeout,  or  deaf  period,  used  to  quench  the 
oscillations  in  the  station,  are  discussed  at  length  in  PRTN  272, 
"SPP  Oscillation"  (see  section  2.2). 

Other  negotiations  this  quarter  were  of  relatively  minor 
significance.  One  bug  in  connection  handling  in  the  PR  was  found 
and  reported  to  Collins  personnel,  who  quickly  fixed  it;  a  second 
bug,  concerning  LROP  priority,  was  suspected  and  became  the  topic 
of  a  discussion  at  the  CAP  5  Implementer s'  meeting  (section  2.1). 

We  also  negotiated  with  other  PRWG  contractors  on  the  best 
way  to  ensure  repair  of  failed  routes;  on  whether  route 
limitations  should  be  resolved  by  increasing  the  route  length  in 
packet  headers  or  by  implementing  transfer  points;  and  on  the 
applicability  of  modelling  work  at  Probe  Corporation  to  issues  of 
network  design  and  PR  deployment.  No  strong  consensus  arose  out 
of  these  negotiations,  but  in  the  last  week  of  the  quarter  we 
participated  in  negotiations  with  Collins  which  promise  to  arrive 
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convenient  to  both  station  and  PR. 
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3.  THE  PACKET  RADIO  NETWORK 

3.1.  Station  Programing  and  Testing 

3.1.1.  Connection  process  and  STACON 

We  designed  and  implemented  modifications  to  the  SPP 
protocol  in  the  station  connection  process.  These  modifications 
correct  a  problem  in  the  protocol,  the  SPP  "oscillation".  This 
problem  allowed  a  PR  and  the  station  to  have  different  notions  of 
the  state  of  connections  between  them,  when  acknowledgements 
(ACKs)  to  synchronize  (SYN,  open)  packets  were  lost  or  delayed 
(for  example,  due  to  packet  printing) .  We  delivered  this  to  SRI, 
where  it  was  used  in  CAP  5  testing,  and  again  later  for  regular 
use.  The  modifications  were  fully  described  in  PRTN  272  (see 
section  2.2). 

Changes  were  made  to  the  station  operator's  terminal  control 
process,  STACON,  to  permit  process  output  streams  to  be  directed, 
by  default,  to  particular  terminals.  The  previous  version  cycled 
through  the  existing  terminals  and  processes,  assigning  them  in 
an  arbitrary,  cyclic  order.  SRI  had  requested  this  modification 
so  that  certain  physical  terminals  in  their  station  room  would 
always  perform  certain  functions.  For  instance,  packet  printing 
would  always  be  performed  on  a  high-speed  scope  terminal  line, 
and  the  operator's  terminal  would  always  be  a  particular  hard 
copy  terminal.  Hardware  problems  and  scheduling  contingencies 
prevented  delivery  of  the  new  STACON  to  SRI  this  quarter,  but  we 
anticipate  delivery  early  in  the  coming  quarter,  when  conditions 
permit. 

3.1.2.  Labeler  and  network  testing 

The  Labeler  was  enhanced  and  extensively  tested  and  debugged 
this  quarter.  Additional  CAP  5  labeler  commands  were  designed, 
written  and  tested,  to  allow  the  station  operator  to  perform 
several  new  functions.  These  functions  refer  specifically  to 
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important  aspects  of  CAP  5,  and  most  do  not  have  any  counterpart 
in  earlier  CAP  versions.  They  are  as  follows. 

a)  Examine  the  neighbor  information  reported  in  the  most  recent 
PDP  —  for  a  particular  PR  or  for  all  PRs. 

b)  Examine  the  reported  link  qualities  and  age  of  links  between 
the  specified  PR  and  its  neighbors  —  for  a  particular  PR  or 
for  all  PRs.  The  age  is  the  duration  of  time  the  link  has 
been  usable  for  routing  assignment. 

c)  Examine  the  time  since  a  PDP  has  arrived  —  for  a  particular 
PR  of  for  all  PRs. 

d)  Tell  the  station  to  generate  a  PDP  request  —  for  a  particular 
PR  or  for  all  PRs. 

e)  View  the  station's  current  notion  of  the  best  route  between 
any  two  PRs. 

f)  Change  the  threshold  values  used  in  determining  good  neighbor 
status,  for  experimental  purposes.  (This  was  requested  at  the 
SRI  meeting  July  11-12.) 

The  vast  majority  of  station  debugging  was  centered  on  the 
new  CAP  5  Labeler,  so  efforts  in  that  domain  are  included  in  this 
section.  Progress  was  very  good  this  quarter,  resulting  in  a 
station  (and  network)  with  no  known  bugs  by  the  end  of  August. 

At  that  time,  activity  had  become  mostly  one  of  load  testing  — 
determining  what  amount  of  traffic  and  connectivity  change 
(primarily  due  to  mobile  operation)  could  be  supported.  Problem 
areas  encountered  in  network  testing  this  quarter  included  the 
following. 

1)  SPP  oscillation,  as  noted  in  section  2.3.  Initially  avoided 
by  turning  off  (disabling)  the  packet  printer  at  BBN,  or  by 
running  at  SRI.  Later  treated  by  a  modification  to  th<> 
connection  process  (see  section  3.1.1). 
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2)  A  long-standing  (years  old) ,  infrequent  bug  started  cropping 
up  more  frequently,  due  to  new  control  structures  in  the 
Labeler  and  to  the  way  it  exercises  the  operating  system.  The 
timer  queue  in  the  BCPL  library  routines  was  losing  the 
Labeler's  refresh  interval  timer,  so  routes  would  not  be 
refreshed.  The  bug  was  laboriously  tracked  down  and  fixed. 

For  a  time,  it  looked  like  a  hardware  problem,  since  it  was 
seen  only  in  the  PDP-11/40  and  not  in  any  PDP-11/34.  Before 
the  problem  was  found,  we  masked  it  by  an  additional 
cross-check,  counting  the  times  when  the  timer  had  been 
erroneously  removed  from  the  queue.  This  permitted  mobile 
testing  for  the  interim.  The  cause  was  a  mismatch  between 
library  and  Labeler  understandings  of  whether  part  of  an 
argument  field  was  ignored. 

3)  Another  long-standing  bug  started  to  appear  frequently,  and 
had  to  be  masked  (while  still  counting  instances)  for  mobile 
testing  before  it  was  fixed.  This  is  the  "ACK  but  no  packet 
sent"  problem,  an  intermittent  problem  regarding  the  cleanup 
of  an  SPP  connection,  between  the  Labeler  and  the  connection 
process.  The  connection  process  would  occasionally  signal  the 
Labeler  that  an  acknowledgement  had  been  received,  but  the 
Labeler  had  no  record  of  sending  any  packet  to  which  this 
could  be  an  acknowledgement.  A  coding  error  was  finally  found 
and  fixed. 

4)  Use  of  the  station-resident  gateway  led  to  unacceptable  levels 
of  congestion  in  the  station  PR,  contaminating  results  of 
tests  (especially  mobile  runs) .  The  exported  gateway  software 
had  been  released  for  some  time,  but  PR  net  testing  was  using 
the  resident  gateway  due  to  scheduling  conflicts  with  Fort 
Bragg  CAP  4.9  software  work,  which  required  one  of  SRl's 
PDP-lls .  The  solution  was  to  wait  awhile  and  install  the 
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exported  gateway  as  soon  as  project  priorities  permitted, 
which  was  late  in  August.  Hardware  unavailability  due  to  a  PR 
hardware  failure  at  SRI,  and  to  IPR  software  development,  also 
contributed  slightly  to  delay  in  mobile  testing. 

5)  Under  staffing  has  been  somewhat  of  a  problem  in  the  intense 
testing  this  quarter.  Even  SRl's  more  generous  staff  size  has 
been  stretched  with  Fort  Bragg  preparations,  continuing  TIU 
work,  and  CAP  5  testing.  The  TOPS-20  command  file  we  prepared 
(see  QPR  18)  helps  SRI  staff  to  capture  ELF  crashes  for  later 
diagnosis,  but  occasions  when  station  processes  themselves 
crash  are  examples  of  when  BBN  personnel  must  be  immediately 
available,  or  the  crash  data  will  be  lost.  Unfortunately,  SRI 
scope  does  not  permit  their  staff  to  learn  XNET  debugger 
commands  to  capture  the  data;  nor  does  BBN  scope  permit 
guaranteed  availability  of  a  knowledgeable  person  on  call. 

6)  As  the  quarter  progressed,  an  increasing  amount  of  time  and 
effort,  on  the  part  of  Collins,  SRI  and  BBN,  was  drained  by 
attacks  on  the  "bad  ID"  problem.  Somehow  information  claiming 
the  existence  of  various  PR  ID  numbers,  to  which  no  actual  PR 
corresponds,  is  entering  the  net.  This  causes  extra  control 
traffic  as  PRs  report  these  bad  IDs  to  the  station,  and  as  the 
station  attempts  to  label  these  phantom  PRs.  The  extent  of 
damage  to  network  performance  is  not  yet  clear,  and  the  origin 
of  the  bad  IDs  is  even  less  understood.  This  remains  a 
serious  problem  as  the  quarter  ends. 

7)  A  serious  problem  was  observed  in  PDP  generation.  The  station 
PR  did  not  respond  to  a  PDP  request  within  12  minutes,  and  had 
not  sent  a  PDP  within  45  minutes.  The  suspected  cause  is 
congestion  in  the  station  PR.  BBN  prepared  a  document  (PRTN 
277;  see  section  2.2)  describing  a  simple  fairness  algorithm, 
and  suggested  it  be  implemented  in  the  PRs.  This  would  insure 
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servicing  of  all  routines  in  the  "grand  loop"  (PR  scheduling 
algorithm)  at  some  minimum  rate.  A  somewhat  different 
fairness  strategy  was  obtained  through  restructuring  of  the 
grand  loop  by  Collins  staff,  and  this  appears  to  work 
satisfactorily. 

8)  A  problem  with  buffer  allocation  in  the  Labeler  was  found  when 
the  system  was  placed  under  load.  It  was  fixed. 

9)  Confusion  over  configuration,  scenario,  traffic  level  and 
effects  to  be  monitored  slightly  hampered  some  testing  efforts 
this  quarter.  BBN  took  temporary  responsibility  for 
scheduling  on-site  mobile  testing  for  the  remainder  of  the 
quarter,  and  drew  up  mobile  test  plans. 

A  number  of  severe  tests  were  used  to  gain  confidence  in  the 

correct  operation  of  CAP  5  station  and  PR  software.  Besides 

normal  tests,  including  mobile  internet  user  traffic  and  SRI's 

"PMON"  monitor  program,  we  employed  the  following  tactics. 

+  Intermittently  turning  on  (enabling)  the  slow  packet  printing 
in  the  BBN  net,  thus  causing  delay  and  congestion  in  the 
station's  connection  process. 

+  Initiating  down  loads  of  PRs. 

+  Temporarily  halting,  or  completely  restarting,  PRs  or  the 
station. 

+  Sending  garbage  information  to  the  Labeler.  (Specific  efforts 
were  not  necessary  to  accomplish  this.  The  PR  net  generates 
bad  IDs,  for  example,  and  PR  software  bugs  over  the  course  of 
development  have  sent  other  garbled  data  to  the  Labeler.) 

4-  Cause  repeated  connectivity  changes,  forcing  the  reassignment 
of  routes  of  several  traffic  streams. 

+  Run  heavy  amounts  of  traffic  internet,  intranet  forwarded  by 
the  station,  and  intranet  point-to-point. 
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The  results  of  this  extensive  testing  have  been  a  very 
robust  Labeler,  plus  the  progress  on  design  issues  and 
suggestions  to  other  contractors  identified  above.  It  also 
proved  possible  to  adjust  timing  intervals  in  the  station  for 
more  efficient  network  performance,  as  a  result  of  insights 
gained  into  network  behavior  from  mobile  testing.  Use  of  the 
exported  gateway,  however,  will  be  the  biggest  improvement  in 
this  area. 

3.1.3.  PR  down  line  load  process 

As  mentioned  in  section  2.3,  we  negotiated  this  quarter  with 
Collins  regarding  a  format  for  IPR  down  line  load  command 
packets.  The  criteria  here  are  compactness  of  packets,  to 
minimize  radio  channel  load;  resemblance  to  IPR  assembler  output, 
to  minimize  complexity  of  reformatting  and  consequent  potential 
for  errors;  and  similarity  of  format  for  loading  all  PRs,  again 
to  minimize  complexity,  chance  of  error,  and  implementation  and 
maintenance  cost.  We  also  received  TIU  loader  server  information 
from  SRI,  relating  to  possible  use  of  that  facility  to  load  the 
IPRs.  The  TIU  mechanism,  however,  uses  a  different  format  (XNET 
debugger  packets)  and  protocol  (internet  protocol) ,  plus  it  is 
ARPANET-based  rather  than  station-based.  For  these  reasons  it 
has  been  decided  that  the  IPR  and  TIU  loader  server  mechanisms 
will  be  completely  distinct.  The  exact  format  of  the  IPR  down 
load  packets  is  still  in  discussion  as  this  quarter  closes. 

We  also  delivered  a  new  PRLOAD  down  line  loader  process  (for 
EPRs) ,  which  accepts  new  connection  open  failure  codes  installed 
in  the  connection  process  this  quarter.  Also,  PRLOAD  is  now 
compiled  with  the  "/X"  switch,  resulting  in  the  "finish"  command 
compiling  a  process  freeze  instead  of  a  halt  instruction.  This 
is  compatible  with  new  ELF  switch  conventions,  which,  without 
this  change,  would  preclude  debugging  a  process  which  simply 
halted.  The  documentation  was  updated  accordingly. 


12 


BBN  Report  No.  4339 


Bolt  Beranek  and  Neman  Inc 


S.1.4.  XRAY  cross-radio  debugger 

A  new  version  of  XRAY ,  the  cross-radio  debugger,  was 
delivered  this  quarter,  incorporating  a  small  change  to  accept 
new  connection  open  failure  codes  from  the  connection  process. 

3.2.  Support 

During  this  quarter  progress  was  made  in  several  PR  network 
support  areas.  We  modified  the  internet  bootstrap  to  use  96-bit 
leaders.  Use  of  96-bit  leaders,  as  opposed  to  32-bit  leaders,  is 
necessary  in  order  to  communicate  with  a  bootstrap  running  in  a 
machine  attached  through  a  port  expander.  The  modified  bootstrap 
was  installed  on  the  disk  at  UCL.  In  the  future,  this  96-bit 
format  bootstrap  will  also  be  used  on  other  gateways  and  on 
Packet  Radio  stations. 

We  also  made  a  design  decision  on  XNET  debugger  protocol 
under  version  4  Internet  Protocol:  there  will  be  no  change  except 
for  conversion  to  the  new  header  format.  This  will  minimize 
conversion  costs. 

We  delivered  various  station  software  to  assorted  disks  at 
SRI,  including  two  deliveries  of  station  software  for  Fort  Bragg. 
We  also  wrote  a  PDP-11/34  bootstrap  and  complete  station  software 
on  a  disk  sent  to  us  by  Collins.  On  this  disk  we  also  placed  two 
IMPll-A  interface  diagnostics,  one  configured  for  the 
station-ARPANET  interface  and  one  for  the  station-PR  net 
interface.  This  disk  has  been  shipped  to  Collins,  where  we 
expect  it  will  permit  the  Collins  station  to  be  brought  up  early 
in  the  following  quarter.  An  initial  plan  to  write  only  the 
bootstrap  on  disk  was  expanded  because  of  indications  from 
Collins  that  their  ARPANET  connection  might  not  be  working,  which 
would  prevent  delivering  the  rest  of  station  software  that  way. 


-  13  - 


BBN  Report  No.  4339 


Bolt  Beranek  and  Newman  Inc. 


Earlier  hopes  that  documentation  and  training  would  permit 
SRI  staff  to  reformat  and  deliver  to  their  own  disks  PR  code  for 
down  line  loading  have  not  been  realized.  There  is  an  issue  of 
operational  complexity,  but  apparently  a  more  significant  issue 
is  the  limitation  of  SRZ  scope.  This  apparently  prevents  SRI 
staff  from  using  XNET,  the  cross-net  debugger,  which  is  essential 
to  such  delivery  of  PR  code.  As  a  result,  although  we  aided  SRI 
in  placing  one  version  of  PR  CAP  code  on  disk,  we  have  continued 
to  perform  this  task  this  quarter.  The  table  below  summarizes 
the  deliveries  made  during  these  three  months. 


CAP 

to 

to 

version 

SRI 

BBN 

comments 

5.0.4 

X 

5.0.5 
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X 

5.1.0 
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X 
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4.  INTERNETWORKING 

4.1.  Transmission  Control  Program  (TCP) 

Three  major  advances  in  TCP  status  occurred  this  quarter: 
testbed  availability  to  users,  delivery  of  Port  Bragg  monitor 
software  to  ISI,  and  testing  against  TIU  software. 

As  this  quarter  opened,  monitor  TCP  and  TELNET  were  made 
available  for  Packet  Radio  group  users  to  test  them.  Users  were 
encouraged  to  schedule  testing  time  with  BBN  personnel,  so  any 
problems  could  be  immediately  tracked. 

The  Fort  Bragg  PR  net  will  be  using  host  computer  facilities 
at  ISI.  These  will  be  accessed  via  TCP  version  4,  so  our  efforts 
to  provide  this  system  software  have  direct  application  in  the 
Port  Bragg  project.  During  this  quarter  we  received  from  ISI  a 
list  of  TOPS 20  Release  3A  monitor  parameters  for  the  Fort  Bragg 
system.  We  built  such  a  system  from  standard  DEC  sources,  with 
the  following  exceptions: 

1.  BBN' s  96-bit  NCP  was  used. 

2.  TCP  version  4.0.1  was  included. 

3.  Internet  4.0.1  was  included,  with  Internet  user  queues. 

We  sent  this  Release  3A  monitor  image  with  internet  Protocol 
(IP),  TCP,  96-bit  NCP,  and  monitor  TELNET  to  ISI.  The  TCP  files 
and  modifications  to  DEC  files  were  sent  on  magnetic  tape  to  ISI 
so  their  staff  can  merge  in  their  local  changes  as  well.  ISI 
found  two  bugs  in  the  NCP  during  installation,  and  a  user  program 
uncovered  a  bug  in  the  TCP.  These  have  been  fixed,  resulting  in 
a  running  system  at  ISI  ready  for  Port  Bragg  use. 

In  addition,  a  program  which  samples  the  program  counter  has 
been  used  to  watch  the  Internet,  TCP  and  TELNET  code.  The 
analysis  of  its  results  has  not  yet  been  completed,  but  already 
it  has  shown  that  a  certain  hash  table  in  the  free  storage 
package  was  overflowing.  This  resulted  in  considerably 
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inefficient  operation.  The  problem  has  been  corrected  and  the 
updated  files  given  to  ISI. 

In  the  third  area  of  TCP  progress  this  quarter,  SRI's  new 
version  4  Terminal  Interface  Unit  (TIU)  program  was  tested  in 
conjunction  with  the  TOPS20  monitor  TELNET.  Problems  were 
discovered  on  both  ends.  Updated  files  for  TOPS20  will  be  sent 
to  ISI  early  in  the  next  quarter,  and  testing  will  continue. 

4.2.  Gateways 

Previous  testing  with  Lincoln  Lab  staff  of  their  software  to 
perform  speech  conferencing  using  the  SATNET  stream  facility  had 
revealed  problems  in  the  SATNET  interface  code  in  our  gateway. 
This  code  has  been  substantially  modified  during  this  quarter, 
and  further  testing  in  cooperation  with  them  is  ongoing. 

We  also  assisted  UCL  staff  this  quarter,  in  testing  Network 
Independent  FTP. 

A  gateway  for  the  Fort  Bragg  station,  which  will  be  ARPANET 
host  46  (octal) ,  has  been  assembled  in  anticipation  of  its 
deployment  there. 

As  described  in  section  3.1.2,  previous  tests  of  network 
performance  have  been  contaminated  by  traffic  to  the 
station~resident  gateway  congesting  the  station  PR.  A  station 
using  an  exported  gateway  to  test  network  performance  under  more 
realistic  conditions  was  released.  Results  from  testing  with  the 
exported  gateway  configuration  are  expected  from  SRI  next 
quarter . 
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5.  HARDWIRE 

During  this  quarter ,  Packet  Radio  unit  1  failed  and  was 
repaired  by  Collins  personnel  during  an  on-site  visit.  Also, 
with  telephone  direction  from  Collins,  we  disabled  auto-restart 
in  both  PRs .  This  had  been  interfering  with  debugging  efforts. 

Vfe  returned  some  borrowed  PR  RF  hardware  to  SRI,  replacing 
it  with  new  equipment.  This  equipment,  coaxial  cable  and 
attenuators,  is  used  to  connect  the  two  PRs  at  BBN.  From  SRI  we 
received  a  5-port  DMA  1822  LSI-11  minigateway/port  expander.  The 
mounting,  installation  And  checkout  of  this  unit  is  proceeding. 

In  trying  to  prepare  the  disk  of  station  software  for 
Collins  (see  section  3.2),  we  twice  encountered  failures  of  the 
"limits"  card  in  the  station  disk  drive.  These  prevented  us  from 
formatting  the  disk  cartridge.  Each  failure  was  repaired  by  DEC, 
finally  permitting  disk  delivery  of  software  to  Collins. 
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